link destination: The portion of a part’s content area that represents the destination of a link.
UI.152. ÉäÉìÉNå≥
link source: The portion of a part’s content area that represents the source of a link.
153. ÉäÉìÉNÉXÉyÉbÉNÅAÉäÉìÉNèÓïÒ
link specification: An object, placed on the Clipboard or in a drag-and-drop object, from which the source part (the part that placed the data) can construct a link if necessary.
154. ÉäÉìÉNèÛãµÅAÉäÉìÉNèÛë‘
link status: The link-related state (in a link source, in a link destination, or not in a link) of a frame.
155. ÉçÉbÉNÅAï€åÏ
lock: To acquire exclusive access to. A part must lock a link source object or link object before accessing its data.
156. ÉÅÉCÉìÉXÉgÉåÅ[ÉWÉÜÉjÉbÉgÅAéÂäiî[ÉÜÉjÉbÉg
main storage unit: The storage unit that holds the contents property (kODPropContents) of a part. A part’s main storage unit, plus possibly other auxiliary storage units referenced from it, holds all of a part’s content.
message interface: An OpenDoc object that provides an interface to allow parts to send messages (semantic events) to other parts, in the same document or in other documents.
160. ÉÅÉ\ÉbÉh
method: An function that manipulates the data of a particular class of objects.
161. ÉÇÅ[É_ÉãÉtÉHÅ[ÉJÉX
modal focus: A designation of ownership of the right to display modal dialog boxes. A part displaying a modal dialog must first acquire the modal focus, so that other parts cannot do the same until the first part is finished.
162. ÉÇÉjÉ^
monitor: A special use of a dispatch module, in which it is installed in order to be notified of events, but does not dispatch them.
name resolver: An OpenDoc object that determines the proper recipient of a semantic event. The name resolver can resolve object specifiers, permitting semantic events to be sent to individual objects within a part.
name space: An object consisting of a set of text strings used to identify kinds of objects or classes of behavior, for registration purposes. For example, OpenDoc uses name spaces to identify part kinds and categories for binding.
nonexclusive focus: A focus that can be owned by more than one frame at a time. OpenDoc supports the use of nonexclusive foci. Compare exclusive focus.
object callback: A function called by the name resolver to allow your part to provide extra information needed for semantic-event object resolution.
175. ÉIÉuÉWÉFÉNÉgÉÇÉfÉã
object model: A feature of Apple events that allows a part to define a hierarchical arrangement of content objects to represent the elements of the part’s content.
object specifier: A designation of a content object within a part, used to determine the target of a semantic event. Object specifiers can be names (“blue rectangle”) or logical designations (“word 1 of line 2 of embedded frame 3”).
UI.177. OLE
OLE: Object Linking and Embedding, Microsoft Corporation’s compound document architecture.
UI.178. OpenDoc
OpenDoc: A multiplatform technology, implemented as a set of shared libraries, that uses component software to facilitate the construction and sharing of compound documents.
179. Open Linking and Embedding of Objects (OLEO)
Open Linking and Embedding of Objects (OLEO): A technology that enables seamless interoperability between OpenDoc and Microsoft Corporation’s Object Linking and Embedding (OLE) technology for interapplication communication. It allows OLE objects to function automatically as parts in OpenDoc documents, and OpenDoc parts to function automatically as OLE objects in OLE containers.
180. Open Scripting Architecture (OSA)
Open Scripting Architecture (OSA): An architecture of messages (semantic events) and handlers that allows users to control parts by means of scripts. Any scripting language that supports the OSA can be used with OpenDoc parts.
outside-in activation: A mode of user interaction in which a mouse click anywhere in a document activates the largest possible enclosing frame that is not already active. Compare inside-out activation.
overlaid frame: An embedded frame that floats above the content (including other embedded frames) of its containing part, and thus need not engage in frame negotiation with the containing part.
183. ÉIÅ[ÉoÅ[ÉâÉCÉhÅAè„èëÇ´
override: To replace a method belonging to a superclass with a method of the same name in a subclass, in order to modify its behavior.
184. ÉIÅ[ÉiÅ[ÅAèäóLé“
owner: For a canvas, the part that created the canvas and attached it to a facet. The owner is responsible for transferring the results of drawing on the canvas to its parent canvas.
185. ÉyÉAÉåÉìÉgÅEÉLÉÉÉìÉoÉXÅAêeÉLÉÉÉìÉoÉX
parent canvas: The canvas closest above a canvas in the facet hierarchy. If there is a single offscreen canvas attached to an embedded facet in a window, for example, the window canvas (attached to the root facet) is the parent of the offscreen canvas.
186. ÉyÉAÉåÉìÉgÉNÉâÉXÅAêeÉNÉâÉX
parent class: See superclass.
UI.187. ÉpÅ[Ég
part: A portion of a compound document; it consists of document content, plus—at runtime—a part editor that manipulates that content. The content is data of a given structure or type, such as text, graphics, or video; the code is a part editor. In programming terms, a part is an object, an instantiation of a subclass of the class ODPart. To a user, a part is a single set of information displayed and manipulated in one or more frames or windows. Same as document part.
UI.188. ÉpÅ[Égï™ófi
part category: A general classification of the format of data handled by a part editor. Categories are broad classes of data format, meaningful to end users, such as “text”, “graphics” or “table”. Compare part kind.
189. ÉpÅ[ÉgÉRÉìÉeÉìÉcÅAÉpÅ[Égì‡óe
part content: The portion of a part that describes its data. In programming terms, the part content is represented by the instance variables of the part object; it is the state of the part, the portion of it that is stored persistently. To the user, there is no distinction between part and part content; the user considers both the part content alone, and the content plus its part editor, as a part. See also intrinsic content, embedded content. Compare part editor; part.
UI.190. ÉpÅ[ÉgÉGÉfÉBÉ^
part editor: An OpenDoc component that can display and change the data of a part. It is the executable code that provides the behavior for the part. Compare part viewer.
191. ÉpÅ[Ég ID
part ID: An identifier that uniquely names a part within the context of a document. This ID represents a storage unit ID within a particular draft of a document.
192. ÉpÅ[ÉgÉCÉìÉtÉHÅAÉpÅ[ÉgèÓïÒ
part info: (1) Part-specific data, of any type or size, used by a part editor to identify what should be displayed in a particular frame or facet and how it should be displayed. (2) User-visible information about a given part, displayed in a dialog box accessed through a menu command.
193. ÉpÅ[ÉgéÌófi
part kind: A specific classification of the format of data handled by a part editor. A kind specifies the specific data format handled by a part editor. Kinds are meaningful to end users, and have designations such as such as “MacWrite 2.0” or “QuickTime 1.0”. Compare part category.
UI.194. ÉpÅ[ÉgÉrÉÖÅ[ÉA
part viewer: A part editor that can display and print, but not change, the data of a part. Compare part editor.
195. ÉpÅ[ÉgÉEÉCÉìÉhÉE
part window: A window that displays an embedded part by itself, for easier viewing or editing. Any part that is embedded in another part can be opened in its own part window. The part window is separate from, and has a slightly different appearance than, the document window displaying the entire document in which the part is embedded.
196. åòéùê´Åià”å≈ínÅjÅAâië±ê´
persistence: The quality of an object that allows it to span separate document launches and be transported to different computers. For example, a part written to persistent storage is typically written to a hard disk.
persistent reference: A number, stored somewhere within a storage unit, that refers to another storage unit in the same document. Persistent references permit complex runtime object relationships to be stored externally, and later reconstructed.
UI.198. ÉvÉâÉbÉgÉtÉHÅ[ÉÄ
platform: A hardware/software operating environment. For example, OpenDoc is implemented on the Macintosh, Windows, and OS/2 platforms.
platform-normal coordinates: The native coordinate system for a particular platform. OpenDoc performs all layout and drawing in platform-normal coordinates; to convert from another coordinate system to platform-normal coordinates requires application of a bias transform.
200. É|ÉWÉVÉáÉìÉRÅ[ÉhÅAà íuÉRÅ[Éh
position code: A parameter (to a storage unit’s Focus method) with which you specify the desired property or value to access.
UI.201. ÉÜÅ[ÉUÅ[ëIëÉGÉfÉBÉ^ÅAóDêÊÉGÉfÉBÉ^
preferred editor: The part editor that last edited a part, or for whom the part’s data was just translated. If a part’s preferred editor is not present, OpenDoc attempts to bind the part to the user’s default editor for kind or default editor for category.
UI.202. ÉÜÅ[ÉUÅ[ëIëéÌófiÅAóDêÊèäëÆ
preferred kind: The part kind that a part specifies as its highest-fidelity, preferred format for editing. It is the part kind stored as the first value in the contents property of the part’s storage unit, unless the storage unit also contains a property of type kODPropPreferredKind specifying another value as the preferred kind.
203. ÉvÉåÉ[ÉìÉeÅ[ÉVÉáÉìÅAï\åªï˚ñ@ÅAï\åªå`éÆ
presentation: A particular style of display for a part’s contents—for example, outline or expanded for text, or wire-frame or solid for graphic objects. A part can have multiple presentations, each with its own rendering, layout, and user-interface behavior. Compare view type.
204. ÉvÉçÉ~ÉXÅAíxâÑïœä∑
promise: A specification of data to be transferred at a future time. If a data transfer involves a very large amount of data, the source part can choose to put out a promise instead of actually writing the data to a storage unit.
205. ëÆê´
property: In the OpenDoc storage system, an element of a storage unit. A property defines a kind of information (such as “name” or “contents”) and contains one or more data streams, called values, that consist of information of that kind. Properties in a stored part are accessible without the assistance of a part editor. See also display property, user property, Apple event property.
206. ÉvÉçÉgÉRÉã
protocol: The programming interface through which a specific task or set of related tasks is performed. The drag-and-drop protocol, for example, is the set of calls that a part editor makes (and responds to) to support the dragging of items into or out of its content.
207. ë„óùì‡óeÅAÉvÉçÉVÉLÅ[ì‡óeÅAë„óùÉRÉìÉeÉìÉc
proxy content: Data, associated with a single embedded frame written to the Clipboard (or drag-and-drop object or link-source object), that the frame’s original containing part wanted associated with the frame, such as a drop shadow or other visual adornment. Proxy content is absent if intrinsic content as well as an embedded frame was written.
208. ÉpÅ[ÉWÅAâèúÅAÉÅÉÇÉäâï˙
purge: To free noncritical memory, usually by writing or releasing cached data. In low-memory situations, OpenDoc can ask a part editor or other objects to purge memory.
UI.209. ì«Ç›çûÇ›
read: For a part or other OpenDoc object, to transform its persistent form in a storage unit into an appropriate in-memory representation. Same as internalize; compare write.
210. ÉåÉRÅ[É_ÉuÉãÅAãLò^â¬î\
recordable: A level of scripting support of a part. A recordable part allows the user to automatically convert user actions into scripts attached to the part. Compare scriptable, tinkerable.
211. ÉäÉtÉ@ÉåÉìÉXÅAéQèΔ
reference: A pointer to (or other representation of) an object, used to gain access to the object when needed.
reference count: The number of references to an object. Objects that are reference-counted, such as windows and parts, cannot be deleted from memory unless their reference counts are zero.
213. ÉäÉäÅ[ÉXÅAâï˙ÅAéQèΔâï˙
release: To delete a reference to an object. For a reference-counted object, releasing it decrements its reference count.
UI.214. çÌèú
remove: For a frame, to permanently delete it from its document, as well as from memory. Compare close.
UI.215. ïúãA
revert: To return a draft to the state it had just after its last save.
root facet: The facet that displays the root frame in a document window.
217. ÉãÅ[ÉgÉtÉåÅ[ÉÄÅAÉãÅ[Égòg
root frame: The frame in which the root part of a window is displayed. The root frame shape is the same as the content area of the window.
218. ÉãÅ[ÉgÉpÅ[Ég
root part: The part that forms the base of a document and establishes its basic editing, embedding, and printing behavior. A document has only one root part, which can contain content elements and perhaps other, embedded parts. Any part can be a root part.
219. ÉãÅ[ÉgÉXÉgÉåÅ[ÉWÉÜÉjÉbÉgÅAÉãÅ[Égäiî[ÉÜÉjÉbÉg
root storage unit: See content storage unit.
220. ÉãÅ[ÉgÉEÉCÉìÉhÉE
root window: See document window.
UI.221. ï€ë∂
save: To write all the data of all parts of a document (draft) to persistent storage.
222. ÉXÉNÉäÉvÉg
script: A sequence of written instructions that, when executed by a script interpreter, are converted to semantic events that manipulate parts.
scriptable: A level of scripting support of a part. A scriptable part is able to accept semantic events for its publicly published content objects and operations. Compare tinkerable, recordable.
224. ëIëÅAÉZÉåÉNÉg
select: To designate as the locus of subsequent editing operations. If the user selects an embedded part, that part’s frame border takes on an appearance that designates it as selected. The embedded part itself is not activated at this stage.
selection focus: A designation of ownership of editing activity. The part whose frame has the selection focus is the active part and has the selection or insertion point. See also keystroke focus.
226. semantic eventÅAÉZÉ}ÉìÉeÉBÉbÉNÉCÉxÉìÉg
semantic event: A message sent to a part or one of its content elements. Semantic events pertain directly to the part’s content model and can have meaning independent of the part’s display context. For example, semantic events could direct a part to get, set, or delete data. Compare user event. See also Open Scripting Architecture.
semantic interface: A set of OpenDoc objects that provides an interface to allow parts to receive messages (semantic events) from other parts, in the same document or in other documents.
228. ÉVÅ[ÉPÉìÉXî‘çÜÅAèòóÒî‘çÜ
sequence number: A number that defines the position of a frame in its frame group.
229. ÉTÅ[ÉrÉX
service: An OpenDoc component that, unlike a part editor, is not primarily concerned with editing and displaying parts. Instead, it provides a service to parts or documents, using the OpenDoc extension mechanism. Spelling checkers or database-access tools, for example, can be implemented as services.
UI.230. ê›íËÉ_ÉCÉAÉçÉO
settings dialog box: A dialog box, accessible through the Part Info dialog box, that displays part-specific user properties.
231. ê›íËã@î\ägí£ÅAê›íËägí£ÉNÉâÉX
settings extension: An OpenDoc extension class that you can use to implement a settings dialog box.
232. ÉVÉFÅ[Év
shape: A description of a geometric area of a drawing canvas.
233. ÉVÉFÉAÅ[ÉhÅEÉäÉ\Å[ÉXÅAã§óLÉäÉ\Å[ÉX
shared resource: A facility used by multiple parts. Examples of shared resources are the menu bar, keystrokes, serial ports, and selection focus. See also arbitrator.
234. åZíÌÅAìØóÒÅAìØÉåÉxÉãÅAÇ´ÇÂǧÇæÇ¢ÉåÉxÉã
sibling: A frame or facet at the same level of embedding as another frame or facet within the same containing frame or facet. Sibling frames and facets are z-ordered to allow for overlapping.
UI.235. è¨ÉAÉCÉRÉìï\é¶å`éÆÅAè¨ÉAÉCÉRÉìï\é¶É^ÉCÉv
small icon view type: A view type in which a part is represented by a 16–by–16 pixel bitmap image. Other possible view types for displaying a part include large icon, thumbnail, and frame.
236. SOM
SOM: See System Object Model.
237. É\Å[ÉXÉRÉìÉeÉìÉcÅAÉ\Å[ÉXì‡óeÅAÉäÉìÉNå≥ì‡óe
source content: The content at the source of a link. It is copied into the link and then into the destination content.
UI.238. É\Å[ÉXÉtÉåÅ[ÉÄÅAÉäÉìÉNå≥ÉtÉåÅ[ÉÄ
source frame: (1) An embedded frame whose part that has been opened up into its own part window. (2) The frame to which other synchronized frames are attached.
239. É\Å[ÉXÉpÅ[ÉgÅAÉäÉìÉNå≥ÉpÅ[Ég
source part: A part that contains information that is displayed in another part through a link. Compare destination part.
split-frame view: A display technique for windows or frames, in which two or more facets of a frame display different scrolled portions of a part’s content.
UI.241. ëÂÉAÉCÉRÉìï\é¶å`éÆÅAëÂÉAÉCÉRÉìï\é¶É^ÉCÉv
large icon view type: A view type in which a part is represented by a 32–by–32-pixel bitmap image. Other possible view types for displaying a part include small icon, thumbnail, and frame.
static canvas: A drawing canvas that cannot be changed once it has been rendered, such as a printer page. Compare dynamic canvas.
UI.243. Ç–Ç»å`
stationery: A part that opens by copying itself and opening the copy into a window, leaving the original stationery part unchanged.
244. ÉXÉgÉåÅ[ÉWÅEÉVÉXÉeÉÄÅAäiî[ÉVÉXÉeÉÄ
storage system: The OpenDoc mechanism for providing persistent storage for documents and parts. The storage system object must provide unique identifiers for parts as well as cross-document links. It stores parts as a set of standard properties plus type-specific content data.
245. ÉXÉgÉåÅ[ÉWÅEÉÜÉjÉbÉgÅAäiî[ÉÜÉjÉbÉg
storage unit: In the OpenDoc storage system, an object that represents the basic unit of persistent storage. Each storage unit has a list of properties, and each property contains one or more data streams called values.
strong persistent reference: A persistent reference that, when the storage unit containing the reference is cloned, causes the referenced storage unit to be copied also. Compare weak persistent reference.
250. ÉTÉuÉNÉâÉX
subclass: A class derived from another class (its superclass), from which it inherits type and behavior. Also called derived class or descendant.
251. ÉTÉuÉtÉåÅ[ÉÄ
subframe: A frame that is both an embedded frame in, and a display frame of, a part. A part can create an embedded frame, make it a subframe of its own display frame, and then display itself in that subframe.
252. ÉTÉuÉVÉXÉeÉÄ
subsystem: A broad subdivision of the interface and capabilities of OpenDoc, divided along shared-library boundaries. The OpenDoc subsystems include shell, storage, layout, imaging, user events, and semantic events. Individual OpenDoc subsystems are replaceable.
253. ÉXÅ[ÉpÅ[ÉNÉâÉX
superclass: A class from which another class (its subclass) is derived. Also called ancestor, base class, or parent class. See also inheritance.
254. ÉXÉèÉbÉvÅEÉgÅ[ÉNÉìÅAÉgÅ[ÉNÉìì¸ÇÍë÷Ƕ
swap token: A special Apple events token that signals OpenDoc of an object accessor’s failure furnish a required token. Passing a swap token causes a switch in the context of object resolution.
synchronized frames: Separate frames that display the same representation of the same part, and should therefore be updated together. In general, if an embedded part has two or more editable display frames of the same presentation, those frames (and all their embedded frames) should be synchronized.
256. System Object Model (SOM)
System Object Model (SOM): A technology from International Business Machines, Inc., that provides language- and platform-independent means of defining programmatic objects and handling method dispatching dynamically at runtime.
thumbnail view type: A view type in which a part is represented by a large (64-by-64 pixels) bitmap image that is typically a miniature representation of the layout of the part content. Other possible view types for displaying a part include large icon, small icon, and frame.
tinkerable: A level of scripting support of a part. A tinkerable part allows the user to customize it, changing its behavior during virtually any user action. Compare scriptable, recordable.
261. ÉgÅ[ÉNÉì
token: (1) A short, codified representation of a string. The session object creates tokens for ISO strings. (2) In Apple events for OpenDoc, a special descriptor structure that a part uses to identify one or more content objects within itself.
262. ÉgÉâÉìÉXÉtÉHÅ[ÉÄÅAïœä∑
transform: A geometric transformation that can be applied to a graphic object when it is rendered, such as moving, scaling, or rotation. Different platforms and different graphics systems have transforms with different capabilities.
263. ÉgÉâÉìÉXÉåÅ[ÉVÉáÉìÅAñ|ñÛÅAïœä∑
translation: The conversion of one type of data to another type of data. Specifically, the conversion of data of one part kind to data of another part kind. The translation object is an OpenDoc wrapper for platform- specific translation capabilities. Note that translation can involve loss of fidelity.
264. ÉgÉâÉìÉXÉåÅ[É^ÅAñ|ñÛÉÜÅ[ÉeÉBÉäÉeÉB
translator: A software utility, independent of OpenDoc, that converts data from one format to another. A translator may, for example, convert text in the format used by one word processor into a format readable by a different one. The translation capability of OpenDoc relies on the availability of translators.
UI.265. éÊÇËè¡Çµ
undo: To rescind a command, negating its results. The undo object holds command history information to support the undo capability of OpenDoc.
used shape: A shape that describes the portion of a frame that a part actually uses for drawing; that is, the part of the frame that the containing part should not draw over.
267. ÉÜÅ[ÉUÉCÉxÉìÉgÅAóòópé“ÉCÉxÉìÉg
user event: A message, sent to a part by the dispatcher, that pertains only to the state of the part’s user interface, not directly to its contents. User events include mouse clicks and keystrokes; they deliver information about window locations, scroll-bar positions, editing actions, and the like. Compare semantic event.
user-interface part: A part without content elements, representing a unit of a document’s user interface. Buttons and dialog boxes, for example, can be user-interface parts.
269. ÉÜÅ[ÉUëÆê´ÅAóòópé“ëÆê´
user property: One of a set of user-accessible characteristics of a part or its frame. The user can modify some user properties, such as the name of a part; the user cannot modify some other user properties, such as part category. Each user property defined by OpenDoc is stored as a distinct property in the storage unit of the part or its frame.
270. óLå¯ÅAóòópâ¬î\ÅAçXêVóvãÅâèú
validate: To mark a portion of a canvas (or facet, or frame) as no longer in need of redrawing. Compare invalidate.
271. íl
value: In the OpenDoc storage system, a data stream associated with a property in a storage unit. Each property has a set of values, and there can be only one value of a given data type for each property.
272. ÉrÉÖÅ[ÉAÅAÉrÉÖÉèÅ[ÅAï\é¶ã@î\
viewer: See part viewer.
UI.273. ï\é¶å`éÆÅAï\é¶É^ÉCÉv
view type: The basic visual representation of a part. Supported view types are large icon, small icon, thumbnail, and frame.
weak persistent reference : A persistent reference that, when the storage unit containing the reference is cloned, is ignored; the referenced storage unit is not copied. Compare strong persistent reference.
UI.275. ÉEÉCÉìÉhÉEÅAÉEÉBÉìÉhÉE
window: An area of a computer display in which information is presented to users in a graphic user interface. Windows typically contain one or more content areas and controls, such as scroll bars, that allow the user to manipulate the display. Window systems are platform-specific.
window-frame transform: The composite transform that converts from a part’s frame coordinates to its window coordinates.
UI.279. ÉEÉCÉìÉhÉEèÛë‘
window state: An object that lists the set of windows that are open at a given time. Part editors can alter the window state, and the window state can be persistently stored.
UI.280. ÉâÉbÉpÅ[
wrapper: An object (or class) that exists to provide an object-oriented interface to a non-object-oriented or system-specific structure. The OpenDoc class ODWindow, for example, is a wrapper for a system-specific window structure.
UI.281. èëÇ´çûÇ›
write: For a part or other OpenDoc object, to transform its in-memory representation into a persistent form in a storage unit. Same as externalize; compare read.
282. zÉIÅ[É_Å[
z-ordering: The front-to-back ordering of sibling frames used to determine clipping and event handling when frames overlap.
